1. Field of the Invention
The present invention relates to the field of integrated circuits and, more particularly, to facilitating more efficient co-simulation of physical implementations of integrated circuits with software environments.
2. Description of the Related Art
Electronic circuit designs can be constructed, simulated, debugged, and translated into electronic hardware using a High Level Modeling System (HLMS). Typically, an HLMS is implemented as a software-based design tool that provides blocks which can be combined to build an electronic circuit. A block refers to a high level software construct that represents a particular circuit function, such as multiplexing, addition, multiplication, or the like. Blocks may have ports that can produce and consume signals, and may be arranged within the HLMS to form a circuit and/or system. Communication among the blocks can be represented by wires, or signals, that graphically link the blocks. The design may be simulated within the HLMS once it is constructed. Some HLMS tools can generate a hardware implementation from the block representation of the circuit design. For example, an HLMS may generate the bitstream necessary to program a field programmable gate array (FPGA) or can generate the hardware description language (HDL) files necessary to specify the hardware design.
One example of an HLMS is System Generator for DSP™ (Sysgen), available from Xilinx, Inc. of San Jose, Calif. Sysgen is a system level modeling tool that facilitates FPGA hardware design. Sysgen provides a wide range of blocks that can be automatically compiled into a design suitable for an FPGA. Among these blocks are high level abstractions that implement complex functions, including digital signal processing as well as communication and control logic. In addition, access to underlying FPGA resources can be provided through low level block abstractions that facilitate the construction of highly efficient FPGA designs.
An electronic design typically is simulated in an HLMS using program logic that models block behavior. It also is possible to incorporate external hardware into an HLMS simulation. The process of simulating a circuit design where a portion of the circuit design is emulated in external hardware which works cooperatively with the HLMS is referred to as hardware co-simulation, or simply co-simulation, as used herein. The portion of the circuit design that is emulated using external hardware executes in a fraction of the time that would otherwise be required were that portion of the circuit design to be simulated in software. In consequence, co-simulation can dramatically increase the speed of simulation.
The “external hardware” used in co-simulation refers to an electronic circuit board, referred to as a co-simulation platform, that hosts one or more programmable logic devices (PLDs). Typically, the PLD is an FPGA, which is highly suited to co-simulation as different circuit descriptions can be compiled and executed on the same hardware device. In any case, the computer system hosting the HLMS is communicatively linked to the co-simulation platform. The portion of the circuit design that is emulated in external hardware is implemented within the PLD.
Presently, before a circuit design can be co-simulated, the PLD that is disposed upon the co-simulation platform must be programmed using an appropriate configuration bitstream. Typically, the PLD is fully reprogrammed at the start of each simulation to ensure it is initialized to a known state. Thus, responsive to a user command to begin co-simulation, the HLMS, prior to starting the simulation, first completely reprograms the PLD. The amount of time needed to program the PLD, however, can be lengthy and varies according to several different factors. These factors can include, but are not limited to, the size of the circuit design, and thus the size of the bitstream being loaded into the PLD, the bandwidth of the communication link between the co-simulation platform and the host processing system, and the like.
PLDs are fully reprogrammed at the start of each simulation to reset the device and place it in a known state. This ensures that the co-simulation hardware remains bit and cycle faithful to the software model from which the PLD implementation was derived. While many components within a PLD, and particularly within an FPGA, can be reset, others cannot. That is, some resources, such as block memories and SRL16 primitives which can be implemented on selected FPGAs available from Xilinx, Inc., lack an explicit reset mechanism. The only way to initialize such components is to fully reload the FPGA. Accordingly, the only way to ensure that circuit design is placed into a known state is to fully reprogram the FPGA prior to beginning each simulation.
It would be beneficial to reduce the amount of time needed to reconfigure a PLD while still ensuring that the device is properly initialized for use with co-simulation.